1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for port type agnostic proxy support for web services intermediaries.
2. Description of Related Art
The term “web services” refers to a standardized way of integrating web-based applications. Web services typically provide business services upon request though data communications in standardized formats called bindings. A binding is a specification of a data encoding method and a data communications protocol. The most common binding in use for web services is data encoding in XML according to the SOAP protocol and data communications with HTTP.
Unlike traditional client/server models, such as an HTTP server that provides HTML documents in response to requests from browser clients, web services are not concerned with display. Web services instead share business logic, data, and processes through a programmatic interface across a network. Web services applications interface with one another, not with users. Because all data communications among web services are carried out according to standardized bindings, Web services are not tied to any one operating system or programming language. A Java client running in a Windows™ platform can call web service operations written in Perl and running under Unix. A Windows application written in C++ can call operations in a web service implemented as a Java servlet.
Today web services are growing across many industries. As web services grow in importance, web services intermediaries are increasingly recognized as means to provide many value-added services. A web services intermediary, generally referred to in this specification as an “intermediary,” is a web services component that lies between a web services client and a web services provider. Intermediaries operate generally by intercepting a request from a client, providing intermediary services, and then forwarding the client request to a web services provider. Similarly, responses from the web services provider are intercepted, operated upon, and then returned to the client. Examples of commercially available products with which web services intermediaries may be implemented include IBM's Web Services Gateway™ and IBM's Web Services BUS™.
Services provided by intermediaries include authentication of sources of requests for target services, message validation for content and for form, and message logging for auditing purposes. Intermediaries may provide management reporting services, number of web service hits, quantity and timing of services used by individual clients, and so on. Intermediaries can be used as caches in support of improved performance by storing frequently changing but frequently requested data such as news stories, for example. Intermediaries can be used for performance improvement in the sense of load balancing, storing requests for services from several clients and forwarding them to a target service during off-peak service hours. Intermediaries may aggregate services, as, for example, an accounting intermediary that accepts requests for account postings that are then forwarded to separate target services for accounts payable, accounts receivable, and general ledger services.
It is common in prior art to implement web services intermediaries so that they are tightly coupled to their target services. That is, a particular intermediary provides intermediary services only to particular target web services. The need for this is clear when, for example, the intermediary provides message validation and must therefore have precise knowledge of proper message content and form. In the terminology of web services, a group of operations is referred to as a “port type.” In this terminology, the restriction of tight coupling means that commonly in prior art, an intermediary service and all target services served by the intermediary service would have the same port type. There are situations, however, where it is useful for an intermediary service to function across port types, such as, for example, a client identity authentication function intended to provide exactly the same authentication function on messages directed to any target service, regardless of port type. Prior art forces additional configuration complexity in such cases, and there is an ongoing need for improvement in web services intermediaries.